GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Programmierstil</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Programmierstil</span></h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr"><p>Ein <b>Programmierstil</b> (engl. <i>code conventions</i>, <i>coding conventions</i>, <i>coding standards</i>) ist in der <a href="Programmierung" title="Programmierung">Programmierung</a> das Erstellen von <a href="Quellcode" class="mw-redirect" title="Quellcode">Quellcode</a> nach bestimmten vorgegebenen Regeln. Er gilt als Teilaspekt von <a href="Softwarequalit%C3%A4t" title="Softwarequalität">Softwarequalität</a>, der insbesondere die <a href="Verst%C3%A4ndlichkeit" title="Verständlichkeit">Verständlichkeit</a> und <a href="Wartbarkeit" title="Wartbarkeit">Wartbarkeit</a> von <a href="Software" title="Software">Software</a>, dies sind Kriterien für Softwarequalität gem. <a href="ISO/IEC_9126" title="ISO/IEC 9126">ISO/IEC 9126</a> (aktualisiert durch <a href="ISO/IEC_25000" title="ISO/IEC 25000">ISO/IEC 25000</a>) unterstützen soll.

</p><p>Ein Programmierstil und die Vorgaben dazu regeln, <i>„wie“</i> ein Programm, d. h. sein Quellcode, in formaler und struktureller Hinsicht gestaltet sein soll – unabhängig davon, <i>„was“</i> das Programm leisten soll. Dabei wirken drei Aspekte zusammen:

</p>

<ul><li>Die <i>Vorschrift:</i> Die Definition von Regeln oder Konventionen/Standards. Im Sinn von (Software-) „Qualität“ (= „das Erfüllen von Anforderungen“) sind dies „Anforderungen“.</li>

<li>Die <i>Handlung:</i> Das Umsetzen/Berücksichtigen dieser Regeln; 'Programmieren' / Erstellen von <a href="Programmcode" title="Programmcode">Programmcode</a></li>

<li>Das <i>Ergebnis:</i> Der <a href="Quelltext" title="Quelltext">Quelltext</a> mit seiner Struktur und seinem Erscheinungsbild; im Rahmen der <a href="Qualit%C3%A4tssicherung" title="Qualitätssicherung">Qualitätssicherung</a> auf Einhaltung der <i>Vorschrift(en)</i> überprüfbar</li></ul>

<p>In einem umfassenderen Sinn gelten auch die <a href="Programmierparadigma" title="Programmierparadigma">Programmierparadigmen</a> als (fundamentaler) Programmierstil.<sup id="cite_ref-1" class="reference"><a href="#cite_note-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>

</p><p>Die Beurteilung eines Programmierstils erfordert in der Regel ein tiefes semantisches Verständnis des Programmquelltextes. Aus diesem Grund sind <a href="Style_Checker" title="Style Checker">Style Checker</a> und <a href="Beautifier" class="mw-redirect" title="Beautifier">Beautifier</a> bisher nicht oder nur äußerst eingeschränkt in der Lage, die Überprüfung auf einen guten Programmierstil bezüglich dieser Elemente durchzuführen bzw. eine Einhaltung gewährleisten zu können.

</p>

<div class="mw-heading mw-heading2"><h2 id="Zweck">Zweck</h2></div>

<p>Der Zweck eines definierten Programmierstils ist die Erleichterung der Arbeit aller an einem Programmierprojekt beteiligten Teammitglieder. Das bezieht sich insbesondere auf die Lesbarkeit, Verständlichkeit und Wartbarkeit von Programm-Quelltext bzw. der Eliminierung vermeidbarer Fehlerquellen in Programmen.

</p><p>Im Sinne der Verständlichkeit und Wartbarkeit kann eine Richtlinie die Verwendung von programmsprachlich erlaubten (aber „unsauberen“) Programmkonstrukten einschränken oder ganz verbieten. Die Einhaltung von vorgängig definierten Nomenklaturen für Variablen, Prozeduren und Klassennamen kann Lesbarkeit und Wartbarkeit eines Programmcodes wesentlich verbessern.

</p><p>Während der Wartung ist die Einhaltung eines definierten Programmierstils noch wichtiger als während der Entwicklung. Als Richtwert gilt, dass 80 % der Lebenszeit eines Softwareprodukts auf die Wartung entfallen. Oft wird ein Programm nicht von der ursprünglichen programmierenden Person gewartet. Umso wichtiger ist es, dass bereits vom ersten Augenblick an ein guter Programmierstil verwendet wird.

</p><p>Ein Programmierstil sollte nicht unbedingt wie eine Doktrin ausgelegt werden. Verstöße dagegen sollten erlaubt sein, sofern sie gut begründet sind. Dies kann in Einzelfällen beispielsweise (beim Programmierstil im engeren Sinne) durch optimierte Platzausnutzung den Überblick verbessern, durch Betonung bestimmter Einzelheiten der Verständlichkeit dienen oder als Ad-hoc-Sonderregel für besondere Codeteile die Ziele des Programmierstils mit anderen Mitteln verfolgen.

</p>

<div class="mw-heading mw-heading2"><h2 id="Beispiele_für_Elemente_des_Programmierstils"><span id="Beispiele_f.C3.BCr_Elemente_des_Programmierstils"></span>Beispiele für Elemente des Programmierstils</h2></div>

<p>Die Inhalte, die Gegenstand eines Programmierstils sind, können von Fall zu Fall unterschiedlich sein. Die Bandbreite reicht von einfachen Vorgaben zur Code-Strukturierung (Einrückungen) bis hin zu Festlegungen für alle das „Wie“ der <a href="Implementierung" title="Implementierung">Implementierung</a> betreffenden Details.

</p><p>In größeren <i><a href="Projekt" title="Projekt">Projekten</a> und Unternehmen</i>, wo viele Beteiligte in der <a href="Softwareentwicklung" class="mw-redirect" title="Softwareentwicklung">Softwareentwicklung</a> zusammenarbeiten, werden die <a href="Anforderung_(Informatik)" title="Anforderung (Informatik)">Anforderungen</a> zum Programmierstil häufig in <i>Programmierrichtlinien</i> festgelegt. Oft bauen diese auf überbetrieblich oder international veröffentlichten Konventionen und Empfehlungen auf; Beispiele sind die „<a href="Ungarische_Notation" title="Ungarische Notation">Ungarische Notation</a>“ oder die „Java-Code-Conventions“.<sup id="cite_ref-JavaOracle_2-0" class="reference"><a href="#cite_note-JavaOracle-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p>Ein Teil der Regeln ist auf die verwendete <i><a href="Programmiersprache" title="Programmiersprache">Programmiersprache</a></i> ausgerichtet. Einzelne oder viele Elemente können situationsbedingt unterschiedlich <i>wichtig</i> sein (von „Muss“ bis zu „nicht relevant“); z. B. abhängig davon, ob die Software nur einmalig oder dauerhaft benutzt werden soll. Im <i>privaten oder nicht-kommerziellen</i> Bereich wenden Softwareentwickler häufig nur einen erlernten oder intuitiv angewendeten, nicht explizit festgelegten Programmierstil an.

</p><p>Beispiele für Elemente des Programmierstils sind nachfolgend gelistet (u. a. aus<sup id="cite_ref-3" class="reference"><a href="#cite_note-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup>):

</p>

<ul><li>Verwenden der üblichen Vorgehensweisen im gewählten Programmierparadigma (z. B. <a href="Objektorientierte_Programmierung" title="Objektorientierte Programmierung">Objektorientierte Programmierung</a>)</li>

<li>Festlegung von <a href="Namenskonvention_(Datenverarbeitung)" title="Namenskonvention (Datenverarbeitung)">Namenskonventionen</a>: Wie sind <a href="Bezeichner" title="Bezeichner">Bezeichner</a> zu wählen?</li>

<li>Anwendung von <a href="Entwurfsmuster" title="Entwurfsmuster">Entwurfsmustern</a></li>

<li>Verwendung von Compilerdirektiven und -Schaltern</li>

<li>Strukturierung des Codes (Einrückungen, Modul-/Prozedurgröße, GOTO-Verbot): Wo sollen Leerzeichen stehen? Wie ist einzurücken? Maximale Zeilenanzahl einer Routine.</li>

<li>Typisierung (Wahl des Typs für ein Symbol oder eine Variable)</li>

<li>Initialisieren von Variablen</li>

<li>Zugriff auf Variable fremder Objekte / Prozeduren</li>

<li>Gestaltung von Funktionsaufrufen (Parameterübergaben, Rückgabewerte)</li>

<li>pflichtgemäß zu verwendende Standardkomponenten, wie <a href="Unterprogramm" title="Unterprogramm">Unterprogramme</a>, <a href="Application_Programming_Interface" class="mw-redirect" title="Application Programming Interface">APIs</a> etc.</li>

<li>Vermeidung von Redundanz und möglichst breite <a href="Wiederverwendbarkeit" title="Wiederverwendbarkeit">Wiederverwendbarkeit</a> – durch <a href="Modularisierung" class="mw-redirect" title="Modularisierung">Modularisierung</a></li>

<li>Unabhängigkeit verschiedener Programmteile (<a href="Modularit%C3%A4t" title="Modularität">Modularität</a>)</li>

<li>Einheitlichkeit bei der Lösung gleichartiger Probleme, z. B. durch <a href="Normierte_Programmierung" title="Normierte Programmierung">Normierte Programmierung</a></li>

<li>Robustheit durch ausführliche Fehler- und Ausnahmebehandlung</li>

<li>Umfang und Form der <a href="Softwaredokumentation" title="Softwaredokumentation">Dokumentation</a>: Je Prozedur, je Zeile; Detaillierungsgrad; abgestimmt auf weitere Dokumente</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Beispiel_Quelltextformatierung">Beispiel Quelltextformatierung</h2></div>

<p>Wichtige Aspekte des Programmierstils sind die Anordnung von untergeordneten Programmelementen (<a href="Einr%C3%BCckungsstil" title="Einrückungsstil">Einrückungsstil</a>), die damit unmittelbar auch auf die Positionierung umschließender Syntaxelemente wie <code>{}</code>, <code>[]</code>, <code>()</code>, <code>BEGIN</code> oder <code>END</code> Einfluss haben, sowie der Einsatz von Leerzeichen und Leerzeilen und die Verschachtelungstiefe untergeordneter Programmelemente.

</p><p>Auch die <a href="Namenskonvention" class="mw-redirect" title="Namenskonvention">Namenskonventionen</a> für Symbole spielen eine gewichtige Rolle im Zusammenhang mit der Bewertung des Programmierstils. Der Name eines Symbols sollte die Funktion oder Verwendungsweise hinreichend erklären oder zumindest andeuten. Da heute ausreichend Speicherplatz für den Code zur Verfügung steht, ist die früher übliche platzsparende Verwendung von Kürzeln wie zum Beispiel „dskmngr“ nicht mehr gerechtfertigt. Häufig wird für unterschiedliche Arten von Symbolen auch eine unterschiedliche Schreibweise verwendet, um so am Symbolnamen ablesen zu können, ob es sich um eine <a href="Variable_(Programmierung)" title="Variable (Programmierung)">Variable</a>, eine <a href="Funktion_(Programmierung)" title="Funktion (Programmierung)">Funktion</a>, eine <a href="Objektorientierte_Programmierung#Klassen" title="Objektorientierte Programmierung">Klasse</a> oder eine <a href="Konstante_(Programmierung)" title="Konstante (Programmierung)">Konstante</a> etc. handelt. (Siehe auch <a href="Ungarische_Notation" title="Ungarische Notation">Ungarische Notation</a>). In diesem Zusammenhang sind auch die Länge und der Umfang von Symbolen sowie deren Deklarationsreihenfolge von Bedeutung.

</p><p>Diese Aspekte der Quelltextformatierung beziehen sich in erster Linie auf die optische Lesbarkeit, dadurch jedoch direkt auch auf die Verständlichkeit eines Programmquelltexts.

</p><p><a href="Style_Checker" title="Style Checker">Style Checker</a> wie beispielsweise <a href="Checkstyle" title="Checkstyle">Checkstyle</a> können die meisten Kriterien für einen guten Programmierstil bezüglich dieser Elemente überprüfen. <a href="Beautifier" class="mw-redirect" title="Beautifier">Beautifier</a> sind in der Lage, durch Umformatierung des Quelltextes die Einhaltung eines guten Stils bezüglich dieser Elemente zu gewährleisten.

</p>

<div class="mw-heading mw-heading3"><h3 id="Umstrittene_Elemente">Umstrittene Elemente</h3></div>

<p>Die folgenden Elemente von Programmierstilen sind umstritten. Es folgt zu jedem Element eine Gegenüberstellung der Argumente der jeweiligen Befürworter und Gegner. Falls möglich und als allgemein akzeptiert betrachtbar, schließt sich eine Empfehlung bezüglich des umstrittenen Elements an die Erörterung an.

</p>

<div class="mw-heading mw-heading4"><h4 id="Kommentare">Kommentare</h4></div>

<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Kommentar_(Programmierung)" title="Kommentar (Programmierung)">Kommentar (Programmierung)</a></i></div>

<p>Als Kommentare sollen nichttriviale oder nichtoffensichtliche Sachverhalte beschrieben, jedoch zum Programmcode in erkennbarer Form redundante Informationen vermieden werden. Die Menge (Frequenz) an Kommentaren soll sich auf zum Verständnis des Programms relevante Informationen beschränken.<sup id="cite_ref-JavaOracle_2-1" class="reference"><a href="#cite_note-JavaOracle-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup> Dies kann auch von der <a href="Programmiersprache" title="Programmiersprache">Programmiersprache</a> (z. B. der Verwendbarkeit ‚<a href="Sprechender_Name" title="Sprechender Name">Sprechender Namen</a>‘) abhängig sein.

</p><p><i>Zu viele</i> Kommentare können auf eher schlechte Codequalität hinweisen. Wo ein Kommentar erforderlich scheint, solle der Entwickler eine alternative Form der Implementierung prüfen.<sup id="cite_ref-JavaOracle_2-2" class="reference"><a href="#cite_note-JavaOracle-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p><i>Zu wenige</i> Kommentare bedeuten im Wartungsfall (z. B. durch andere Entwickler) zu höherem Aufwand für die Einarbeitung ins oder das Verständnis für das Programm führen, im schlimmsten Fall zu Fehlimplementierungen führen.

</p><p>Früher galt die Abwesenheit von <a href="Kommentar_(Programmierung)" title="Kommentar (Programmierung)">Kommentaren</a> im Quellcode generell als Zeichen für einen schlechten Programmierstil. Man ging davon aus, dass Kommentare unerlässlich wären. Seit <a href="Refactoring" title="Refactoring">Refactoring</a> und <a href="Clean_Code" title="Clean Code">Clean Code</a> wird das differenzierter gesehen. <a href="Robert_Cecil_Martin" title="Robert Cecil Martin">Robert Cecil Martin</a> weist beispielsweise darauf hin, dass Kommentare niemals schlechten Code ausgleichen und Code stets <i>selbsterklärend</i> sein sollte. Er unterscheidet zwischen „guten“ und „schlechten“ Kommentaren.<sup id="cite_ref-4" class="reference"><a href="#cite_note-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading4"><h4 id="Zeilenlänge"><span id="Zeilenl.C3.A4nge"></span>Zeilenlänge</h4></div>

<p>Oft wird eine Begrenzung der Zeilenlänge als guter Programmierstil angesehen. Für eine solche Begrenzung spricht (je nach festgelegter Maximal-Zeilenlänge), dass

</p>

<ul><li>kürzere Zeilen in der Regel leichter lesbar sind als längere (insbesondere leichter als mehrere lange, automatisch nur an Wortgrenzen umbrochene Zeilen untereinander), siehe den <a href="Spaltensatz#Mehrspaltiger_Satz" title="Spaltensatz">mehrspaltigen Satz</a> von Zeitungen</li>

<li>sich längere Anweisungen meist semantisch in einzelne Teile/Zeilen untergliedern lassen</li>

<li>Vergleichswerkzeuge wie <a href="Diff" title="Diff">diff</a> oft zeilenweise arbeiten und dabei Änderungen leichter zu erkennen sind</li>

<li>bei Beschränkung auf den sicheren druckbaren Bereich (80 Zeichen) semantisch motivierte Zeilenumbrüche und Einrückungen auch im Ausdruck erhalten bleiben</li></ul>

<p>Gegen eine Begrenzung der Zeilenlänge (also <i>für</i> ungekürzte Zeilen) spricht, dass

</p>

<ul><li>dies Handarbeit entweder beim Programmieren oder bei der Einrichtung der IDE erfordert</li>

<li>insbesondere neuere APIs lange Symbolnamen verwenden, was die Entstehung sehr langer Zeilen begünstigt</li>

<li>bei einer Suche mit <a href="Grep" title="Grep">grep</a> die Fundstelle – per Voreinstellung eine einzelne Zeile ohne Kontextzeilen – die vollständige Anweisung zeigen kann</li></ul>

<p>Als Konsens kann gelten, dass auch lange Zeilen keinesfalls mehr als eine Anweisung enthalten sollen.

</p>

<div class="mw-heading mw-heading4"><h4 id="Einrückungsstil"><span id="Einr.C3.BCckungsstil"></span>Einrückungsstil</h4></div>

<p>Der <a href="Einr%C3%BCckungsstil" title="Einrückungsstil">Einrückungsstil</a> ist wohl der umstrittenste Punkt eines Programmierstils.

</p><p>Folgende Empfehlungen gelten jedoch als allgemein anerkannt:

</p>

<ul><li>Festlegung innerhalb eines Projekts, Teil-Projekts, Teams oder Unternehmens. Beispiel: „Für unsere Open-Source-Projekte in C und C++ verwenden wir die GNU-Coding-Standards, für Java grundsätzlich die Code Conventions von SUN und ansonsten die gemäß Allman.“</li>

<li>Konsequente Umsetzung</li>

<li>Keine Mischung unterschiedlicher Stile in einem Projekt</li></ul>

<p>Ebenfalls viel diskutiert ist die Frage der Einrückungstiefe für untergeordnete Blöcke und ob man dabei Leerzeichen oder dem <a href="Tabulatorzeichen" title="Tabulatorzeichen">Tabulatorzeichen</a> den Vorzug geben sollte. So schreibt die Code Convention für Java beispielsweise eine Einrückungstiefe von vier Leerzeichen, die Code Convention für Linux hingegen eine Einrückungstiefe von acht Zeichen vor. Der Vorteil der Einrückung mit Leerzeichen besteht darin, dass die Einrückung unabhängig von den Anzeigeoptionen des Anzeigeprogramms oder Editors stets erhalten bleibt.

</p><p>Tabulatorzeichen zur Einrückung bieten im Gegenzug den Vorteil, dass jeder Entwickler selbst durch die Konfiguration der <a href="Tabulatorstopp" title="Tabulatorstopp">Tabulatorschrittweite</a> seines Texteditors die dargestellte Einrückungstiefe bestimmen kann. Einigkeit besteht jedoch bezüglich der Auffassung, dass man beide Varianten nicht mischen sollte. Eine Mischung von Tabulator- und Leerzeichen bei der Einrückung führt zu uneinheitlichen Einrückungstiefen für Elemente auf der gleichen Hierarchiestufe, was der Lesbarkeit eher abträglich ist.

</p>

<div class="mw-heading mw-heading3"><h3 id="Regelwerke">Regelwerke</h3></div>

<p>Einige Qualitätsnormen im Softwareumfeld (<a href="IEC_61508" title="IEC 61508">IEC 61508</a>, <a href="CMMI" class="mw-redirect" title="CMMI">CMMI</a>, <a href="Spice_(Norm)" class="mw-redirect" title="Spice (Norm)">SPICE</a> usw.) fordern explizit die Anwendung bestimmter Regelwerke für die Programmierung. Beispielsweise ist im Umfeld der Automobilindustrie häufig der Programmierstandard <a href="MISRA-C" title="MISRA-C">MISRA-C</a> vorgeschrieben.

</p>

<div class="mw-heading mw-heading2"><h2 id="Siehe_auch">Siehe auch</h2></div>

<ul><li><a href="Codequalit%C3%A4t" title="Codequalität">Codequalität</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="Literatur">Literatur</h2></div>

<ul><li>Joseph Bergin: <cite style="font-style:italic">Coding at the Lowest Level</cite>. Coding Patterns for Java Beginners. Hrsg.: Pace University. (<a rel="nofollow" class="external text" href="http://csis.pace.edu/~bergin/patterns/codingpatterns.html">pace.edu</a> [abgerufen am 19. Februar 2010]).<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Programmierstil&rft.au=Joseph+Bergin&rft.btitle=Coding+at+the+Lowest+Level&rft.genre=book" style="display:none"> </span></li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<ul><li><a rel="nofollow" class="external text" href="https://google.github.io/styleguide/javaguide.html">Google Java Code Style</a> (englisch)</li>

<li><a rel="nofollow" class="external text" href="http://www.gnu.org/prep/standards/">The GNU Coding Standards</a> (englisch)</li>

<li><a rel="nofollow" class="external text" href="https://www.kernel.org/doc/html/latest/process/coding-style.html">Linux Kernel Coding Style</a> (englisch)</li>

<li><a rel="nofollow" class="external text" href="http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/style.9?query=style%26arch=i386">OpenBSD Kernel source file style guide (KNF)</a> (englisch)</li>

<li><a rel="nofollow" class="external text" href="http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/2/00000489.html">ActionScript Coding Standards von MacroMedia</a> (englisch)</li>

<li><a rel="nofollow" class="external text" href="http://edn.embarcadero.com/article/10280">Object Pascal Style Guide</a> (englisch)</li>

<li><a rel="nofollow" class="external text" href="http://pear.php.net/manual/en/standards.php">PHP PEAR Coding Standards</a> (englisch)</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-1"><span class="mw-cite-backlink"><a href="#cite_ref-1">↑</a></span> <span class="reference-text">Andreas Schwill, Uni Paderborn: <a rel="nofollow" class="external text" href="http://www.hyfisch.de/didaktik/Forschung/INFOS95.pdf"><i>Programmierstile im Anfangsunterricht</i></a></span>

</li>

<li id="cite_note-JavaOracle-2"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-JavaOracle_2-0">a</a></sup> <sup><a href="#cite_ref-JavaOracle_2-1">b</a></sup> <sup><a href="#cite_ref-JavaOracle_2-2">c</a></sup></span> <span class="reference-text"> Oracle <i>Code Conventions for the Java TM Programming Language</i><a rel="nofollow" class="external text" href="http://www.oracle.com/technetwork/java/codeconvtoc-136057.html">oracle.com</a><i>(1999)</i></span>

</li>

<li id="cite_note-3"><span class="mw-cite-backlink"><a href="#cite_ref-3">↑</a></span> <span class="reference-text">Uwe Sauerland: <a rel="nofollow" class="external text" href="http://uwe-sauerland.de/richtlinien/Programmierstil.html"><i>Richtlinien zum Programmierstil</i></a></span>

</li>

<li id="cite_note-4"><span class="mw-cite-backlink"><a href="#cite_ref-4">↑</a></span> <span class="reference-text">Robert Cecil Martin: <cite style="font-style:italic">Clean Code. A Handbook of Agile Software Craftsmanship</cite>. Prentice Hall, Upper Saddle River NJ u. a. 2008, ISBN 978-0-13-235088-4, 4. Comments, <span style="white-space:nowrap">S.<span style="display:inline-block;width:.2em"> </span>53–74</span>.<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abookitem&rfr_id=info:sid/de.wikipedia.org:Programmierstil&rft.atitle=4.+Comments&rft.au=Robert+Cecil+Martin&rft.btitle=Clean+Code.+A+Handbook+of+Agile+Software+Craftsmanship&rft.date=2008&rft.genre=bookitem&rft.isbn=9780132350884&rft.pages=53-74&rft.place=Upper+Saddle+River+NJ+u.+a.&rft.pub=Prentice+Hall" style="display:none"> </span></span>

</li>

</ol></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2024-07-02" href="https://de.wikipedia.org/wiki/?title=Programmierstil&oldid=246396536">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>